In the past, there have been different types of time formats used to count time in devices to ensure that actions and events occur correctly. Such time formats include universal time (UTC) formats such as Global Positioning Satellite (GPS) and Inter Range Instruction Group (IRIG-B), as well as time formats which do not use UTC, such as the IEEE 1588 Standard Precision Time Protocol (PTP). The IEEE1588 Standard in particular defines a method for sub-microsecond synchronization of clocks and other devices, such as sensors, actuators and other terminal devices, on a standard Ethernet-based network or other distributed application utilizing commercially available technology. In such systems, typically, there is a master unit and a plurality of slaves.
In PTP, each slave or local unit has a precision clock that provides a local time source. Thus, if a master requires two slave devices to perform actions at the same time, the master sends a message to each slave device, including the time that the action must be performed. However, each slave or local unit must also have a local time counter. The slave devices will then perform the actions at the time referenced by its own local clock. If the clocks on the slaves are not synchronized then the operations may not be performed as desired. Moreover, if the slaves are not all on the same time format, the time must be converted to the appropriate time format for the operations to be performed as desired.
Accordingly, because devices in a network may not all operate in the same time format, it is also necessary to periodically convert from one time format to another time format. Conversion from one time format to another time format will typically occur in a processor due to the complexity of the logical conversion algorithm.
Unfortunately, the processor will likely be performing other tasks when the request for time conversion is made. Furthermore, it is not predictable how long will be required for the processor to complete the other tasks and/or be interrupted to perform the time conversion. As such, there is an inherent CPU latency that arises when time conversion occurs. Clearly, this CPU latency affects the accuracy of the time conversion. Furthermore, the network load and demands on the processor are transient and even over short spans of time cannot be easily estimated. As such, there is an inherent degradation and inaccuracy that arises when the time conversion occurs due to unpredictable CPU latency.
Furthermore, it is appreciated that the same time conversion will be occurring in a number of local units. The time conversion latency at each local unit will differ and could be compounded. It is also understood that if time conversion occurs several times from one source, such as a master unit having a global positioning satellite antenna, each occurrence of time conversion can add additional error such that local nodes located further from the master unit may have an increased accuracy degradation caused by successive conversions. As such, the cumulative error that might arise from time conversion at each of the local units can be significant such that the local units will not all be synchronized and the operations may not be performed as desired.
Other prior art systems have used GPS antennas at each subnet to facilitate the transfer of timing information across remotely located subnets and increase accuracy amongst remotely located subnets. However, such systems are limited to GPS time formats because they obtain the time from orbiting satellites and cannot easily utilize non-UTC time formats such as the 1588 Standard. Furthermore, such systems require a separate GPS antenna at each subnet which increases the cost and complexity of the overall system. In addition, if a GPS antenna at one subset fails, the time accuracy throughout the network could be affected.
Accordingly, there is a need in art for a method and device to facilitate conversion between different time formats at a local clock utilizing a processor without accuracy degradation arising from processor latency.